typescript-eslint rule prefer-optional-chain is buggyThe typescript-eslint ESLint plugin’s rule prefer-optional-chain is buggy on 5.35.1, it’s blocking me from bumping all deps in the monorepo. It took me around 4 hours to investigate, extract and raise https://github.com/typescript-eslint/typescript-eslint/issues/5556
People also raised similar issues regarding the latest prefer-optional-chain.
I hope maintainers will fix it soon.
Until it’s fixed, don’t bump it beyond 5.33.1.
Mr Toh posted a good article comparing various means to strip tags from HTML, including our npm package string-strip-html.
To add 2p.
It’s not just about speed.
The primary reason why you’d use an npm package, rather than regex, is whitespace management. The string-strip-html ensures the stripped results looks as if a human deleted the tags. Our program can even be used to generate email text versions, placing URLs besides the stripped link labels.
The second reason is string-strip-html can tackle broken HTML, dirty HTML and HTML mixed with other languages.
The third reason is string-strip-html saves you time: writing unit tests, writing correct type definitions (you’re using TypeScript, right?) and tackling edge cases.
Interestingly, the scanerless-parser algorithm of string-strip-html is paying off. It strips JSX tags from MDX! I’m using it myself, on this website, to build the fuse.js search indexes.
string-truncator in actionWe’ve just published a new npm package, string-truncator. First and foremost, it’s for our own use. A picture is worth a thousand words; here’s our <aside>, before and after:
The string truncation is optimised to fit in as much letters as possible within “X line length across Y lines”.Check it out!
“Our obsession with quality is renowned as every Jaeger‑LeCoultre watch undergoes strict “1,000 Hour Control” testing.”
—official websiteopens in a new tab
I wonder, what would be the Software Engineering field equivalent of that?
As you know, JSDelivr broadcasts all npm content from its CDNs for free. You can access any file of any package’s version ever published to npm. For example, there are “ever-green” URLs:
https://cdn.jsdelivr.net/npm/detergent/dist/detergent.umd.js
and exact versions:
https://cdn.jsdelivr.net/npm/detergent@3.2.0/dist/detergent.umd.js
Besides this cdn. URL, there’s also a purge URL — replace cdn. with purge.:
https://purge.jsdelivr.net/npm/detergent/dist/detergent.umd.js
Calling that URL will trigger JSDelivr to purge the CDN assets and fetch the latest from npm. That’s handy with ever-green UMDs because they power GUI’s (like these), and it can take up to a day for CDN to fetch the latest.
Don’t know if you noticed but many extraordinary developers mastered their code editors to such level, that they started teaching productivity, editor plugins and, heck, in some cases, writing code editors.
The first two quick examples that pop to my mind:
It does not matter what code editor you use but it’s imperative to master all keyboard shortcuts and tricks of the one you picked.
autoprefixerCodsen.com runs on Remix, the framework which won’t process anything CSS-related. To scale the styling task, some people use Tailwind; I use good old SASS on style-dictionary design tokens. SASS CLI watches the styles folder with .scss files from outside Remix and places the processed files inside the Remix project folder. From Remix’s point of view, CSS files just magically appear and update themselves.
Enter Autoprefixer. It doesn’t fit into this workflow! We either need to set up a proper JS-script pipeline (à la Gulp) or, two-level setup with an intermediary folder where Autoprefixer CLI’s watches the output of SASS directory (so two CLI’s watching), or some fancy terminal pipe contraption.
None of the options seem suitable.
The alternative is to run VSCode plugin manually, on .scss files.
I’m OK with that, this website needs to be simple.
Few arguments in favour to BYOD company policies:
It’s a day off today and I’m adding exports to all unexported-yet TS types and interfaces defined in every program, especially Opts and Res:
like that⤴, on every single program-package.
PS. I can’t stop thinking about deno and being able to run TS natively. How nice would it be to have the whole monorepo in deno, on rust tooling! Theoretically, we could get rid of: prettier, uvu, c8, esbuild, benchmark, turbo, and (shocker) eslint.
Our packages email-comb and html-crush had dedicated GUI websites and considerable amount of people have been using them. Over time, these two websites became hard to maintain; they were coded in vanilla JS without consistent components, tests and styling. Since they were created, a lot has changed; for example, Remix.js appeared and shook up everything. For example, the codsen.com theme toggle detects when a user switches the theme on the OS Preferences panel. There’s also no initial flash either. Those two old websites didn’t have this technology.
It took me a few weeks to recode them on codsen.com. Five minutes ago, I set up the redirects:
Plus, I created a playground for string-strip-html; it didn’t have a domain before.
The next one is https://detergent.io — the final remaining dedicated library GUI website. I have a few ideas on further improving both the package and its GUI, so I kept them to the last.
2022-SEPT-11 update: detergent.io has been migrated to codsen.com playground.
Codsen.com was previously on Eleventy, pure static HTML+CSS, served from the Edge via Cloudflare workers.
The problems with that setup were:
wrangler program which serves the sites is buggyI’m sure most of that could be solved one way or another. But I just outgrew the 11ty baby shirt.